1. Field of the Invention
This invention relates generally to systems for transferring logical data between an application program running in a central processing complex (CPC) and a peripheral data storage device (PDSD) and, more specifically, to such a system that adapts the block size of such transfers to optimize transfer efficiency responsive to PDSD capability without modifying the predetermined record storage formats and without changing the existing application program.
2. Discussion of the Related Art
A glossary of the acronyms used throughout this discussion is provided herein below. The performance of a data processing computer system can be limited by tasks requiring intensive computations (compute-bound jobs) or tasks requiring intensive data transfers between processor and storage (I/O-bound jobs). Most peripheral data storage devices (PDSDs) employ electromechanical devices and thereby limit data transfer rates well below central processing complex (CPC) capacity. Accordingly, it is a well-known practice in the art to separate the I/O data transfer function from the central processing unit (CPU) within the CPC and relegate it to a independent I/O channel subsystem (CS). Similarly, data management access methods (AMs) and an I/O control program (IOCP) are used to separate the control of I/O operations from an application program.
The CS known in the art provides a generalized interface to permit the application programs within CPC to communicate with any attached PDSD through AM requests to the IOCP. The IOCP controls PDSD operation by initiating the execution of special channel program (CP) instructions. A CS typically contains one or more channels that provide such an interface, which is denominated a "channel path". IOCP communication with any I/O device such as a PDSD is directed through a logical facility within the CS denominated a "subchannel".
The channel path is the logical or physical interconnection of a channel to the connected PDSDs. A CS has one channel path associated with each installed channel. The application program in CPC typically initiates communication with the CS through execution of logical read and write requests to the AM, which may organize the data into blocks to improve PDSD efficiency. Conversely, the CS may initiate communication with the IOCP in CPC through the signalling of an I/O interrupt. The IOCP then signals the application program of read/write completion when appropriate. Following execution of an I/O instruction to initiate an I/O operation, the CS assumes all subsequent responsibility for the execution of an associated CP. In general, the CPC continues processing other instructions while the CS processes the CP. When the CP processing is terminated, the CS then interrupts the IOCP in CPC to signal I/O completion and awaits further I/O instructions. Typically, the IOCP then proceeds to the next I/O instruction for which an AM request is pending.
It is a well-known practice in the art for the AM in CPC to create a CP within the CS in response to application requests. Such a CP is executed by the CS to effect a specified data transfer between the CPC and a selected peripheral device such as a PDSD. The CP usually consists of one or more channel-command words (CCWs), each containing a single transfer command (TC) code for execution by the peripheral device. The IBM Enterprise Systems Architecture/390 (ESA/390) operating system includes a typical example of such an I/O architecture, which can be fully appreciated with reference to ESA/390 Principles of Operation, International Business Machine Corporation, Armonk, N.Y., Document No. SA22-7201. Other data transfer architectures are briefly discussed in "Computer Architecture and Parallel Processing", edited by Kai Hwang, et al, McGraw Hill, New York (1984), pp. 118-140.
There has long been a clearly felt need in the art for improved data transfer efficiency between CPC and PDSD. Speed differences of many orders of magnitude still exist between CPC and PDSD. The art is replete with efforts to accomplish such improvements. Much of this effort concentrates on the design and execution of the CP. For instance, useful CCW data and command chaining schemes for optimizing CPs are disclosed in Japanese Patents JP 01-302456, JP 55-74624, and JP 54-114134 and in U.S. Pat. No. 4,843,544.
J. K. Reser ("Method For Transferring Large Amounts of Data to Streaming Tapes", IBM Technical Disclosure Bulletin, Vol. 31, No. 6, Nov. 1988, pp. 341-342) suggests an enhancement to the Virtual Machine system that permits the dynamic creation of CCW strings for transferring data to and from streaming tape drives. Essentially, his technique involves the accumulation of CCWs to form a "dynamic" CP by adding CCWs until a threshold is met, whereupon the growing CID is then closed and executed. Similarly, in U.S. Pat. No. 5,016,160, Shawn M. Lambeth, et al teach a computer system having a system memory data transfer scheme that accumulates CCWs having contiguous indirect data address word (IDAW) to reduce direct memory access (DMA) overhead. Thus, in effect, Lambeth et al also teach a system for adapting a CP by accumulating various CCWs responsive to channel efficiency considerations. Also, in U.S. Pat. No. 5,023,829, Yoshikazu Shibata discloses a data transfer system that adapts each CCW to the available PDSD buffer space. Shibata's method applies to write operations only. Although his technique permits the CPC to dynamically adapt the CP to accommodate different direct access storage device (DASD) data buffer sizes by dividing the data transfer requirement into more or fewer CCWs of varying extent, Shibata neither considers or suggests a method for adapting the CP to optimize channel efficiency in both directions.
Other efforts are focused on improving the particular CCW architectures available for building the CID. For instance, in U.S. Pat. No. 5,101,477, Daniel F. Casper, et al disclose a data transfer scheme for transferring data between a buffer and storage device within a PDSD. Casper et al teach a PDSD buffer/storage scheme but do not suggest how it may be exploited, through the careful design of CCWs, to improve the efficiency of PDSD data transfers. Similarly, in U.S. Pat. No. 4,843,544, Keith B. DuLac, et al teach a method of operating a finite state machine to control the storage operation between buffer and disk in a PDSD but do not suggest whether their method could also support new and useful CCW architectures.
Unfortunately, in a data processing system exemplified by the IBM ESA/390, the quantity of data transferable by a single CCW is limited in accordance with the data block count field within the CCW. For the ESA/390, the CCW count field is 16-bits, which effectively limits the size of a logical data block (LDB) transferred by a single CCW to 64 kilobytes (kB). This in turn limits subchannel performance because a significant amount of time is required in the PDSD for the "command decode" procedure at the beginning of each CCW and for the "status presentation" procedure at the completion of each CCW.
Such an artificial performance limitation arises mainly from the host software and hardware specifications. Such specifications could be easily changed to, say, increase the count field size in each CCW, but such changes would merely create a "new" operating system incompatible with all existing operating systems and software. The "new" system would thus be useless for improving an existing installed data processing base. Although many practitioners have proposed methods for improving CP efficiencies involving both software and hardware schemes, none have considered or suggested fully downward-compatible methods for increasing the transfer efficiency of single CCWs in an operating system such as the ESA/390. Indeed, most merely propose methods for adapting the CP by varying the numbers of individual CCWs. Until now, an adaptive, user-transparent method for reducing CCW "command decode" and "status presentation" overhead for large data transfers was unknown in the art. The related unresolved problems and deficiencies are clearly felt in the art and are solved by this invention in the manner described below.